Business Analyst Community & Resources | Modern Analyst

BA ABCs: “C” is for Class Diagram

Adrian M. — Thu, 01 Mar 2012 06:36:00 GMT

Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post.

You can find the article here:

BA ABCs: “C” is for Class Diagram

Here are the previous two posts:

BA ABCs: “A” is for Activity Diagram

BA ABCs: “B” is for BPMN

Business Analysis Conference Europe 2010

Adrian M. — Sun, 08 Aug 2010 06:36:00 GMT

The Business Analysis Conference Europe 2010 is building on its highly successful inaugural conference with more workshops and a third track – Business Agility and Business Analysis. It brings together business analysis specialists from across Europe and beyond, providing a platform for promoting the BA profession and opportunities for BAs’ professional development.

The conference runs from 28th to 30th September 2010.

This year we have partnered with the IIBA UK to run an online pre Conference series. Conference speakers will be providing articles to give a real insight into the benefits of attending the Business Analysis Conference in Europe.

One of the keynote speakers, John Seddon, has contributed a piece on the Systems approach to the design and management of service organisations.
The Telegraph described John as a 'reluctant management guru', a description John accepts as his interest is in changing management thinking.

(John Seddon’s key note Conference contribution is described here)

Ellen Gottesdiener and Allan Kelly who are recognized experts on Agile, will share their views on business analysis and Agile from both sides of the pond.

(Ellen Gottesdiener’s Conference contribution is described here)
(Allan Kelly’s Conference contribution is described here)

Joe Da Silva is an experienced business analyst for Skandia who will explore the diverse roles a business analyst can play. (His conference presentation explores his experience in Enterprise Analysis when his organisation recognized the benefits of using internal business analysts instead of expensive, external consultants).

(Joe Da Silva’s Conference contribution is described here)

These are just a few of the articles that are planned and there may be a webinar in the last couple of weeks prior to the conference.

Business analysis is now the central discipline for defining creative and agile options for business change and ensuring that solutions meet business needs. The Business Analysis Conference 2010 will provide an interactive forum where business analysts can learn and debate the essential competencies needed to rise to the challenges faced by their organisations today and in the future.

Read more about the Business Analysis Conference Europe 2010 here.

IMPORTANT DISCOUNTS:
There is a 10% discount available to IIBA members and 15% available to members of the UK Chapter. There is also a discount of up to 25% for group bookings.

Modern Analyst members and Business Analyst Mentor (www.bamentor.com) readers qualify for a 10% discount (Note: this cannot be combined with any other discounts).

BABOK 2.0 Free Download/Access (V2)

Adrian M. — Sat, 17 Apr 2010 04:35:00 GMT

I've seen so many questions being asked by people looking for a free download of the BABOK® 2.0 (Business Analysis Body of Knowledge®).

And the clear answer is yes and no.

Members of the IIBA (International Institute of Business Analysis) can download the BABOK® 2.0 for free from the IIBA's website (login required).

Outside of that, there is no other legal way to download BABOK® Guide.

But do not despair! The IIBA has placed a version of the BABOK® on Google books which, while it cannot be downloaded, it can be accessed via the web and it's free.

Here is the link to BABOK® Guide you can access for free:

Business Analysis Body of Knowledge® (BABOK®) on Google Books

While not a free download, there are also other ways to get information about the BABOK®:

Article: An Introduction to the Business Analysis Body of Knowledge (BABOK 2.0)

Buy a hard copy of the Guide to the Business Analysis Body of Knowledge (BABOK®)

Eliciting Business Rules with an Eye for Data Requirements

Adrian M. — Fri, 27 Nov 2009 06:31:00 GMT

“Business Rules and Data Requirements: Pulling in Tandem for Success” was the title of another session I attended at the WCBA conference. Mary Gorman, Senior Associate with EBG Consulting, focused on business rules and their relationship to data in the context of requirements elicitation.

Copyright Notice: Major portions of this blog post are from materials © EBG Consulting, Inc., 2009 Used with permission on ModernAnalyst.com

Before even diving into the mean of the presentation, Mary stressed the importance of realizing that no one requirements view or model is enough, by itself, do understand the requirements of a given system.

She covered again the four key requirements viewpoints:

Behavior: e.g. process, action, function, task, script
Structure: e.g. information, data, object
Dynamics: e.g. time, lifecycles
Control: e.g. business rules – the intersection of Behavior, Structure, and Dynamics

All these four views are very important and rely on each other to provide a holistic perspective of the requirements.

They key takeaways, for me, from the sessions were:

Process/behavior requirements cannot stand by themselves but instead they trace to data and business rules (just process sis like sitting on a one legged stool)
There is great risk when performing single-dimension requirements elicitation focusing on only one of the requirement viewpoints: business rules alone, business data alone, business process alone, etc.

That’s why you don’t see too many dedicated “Business Rule Analysts” or “Business Process Analyst”. The analyst must be a generalist or, as Scott Ambler likes to say a “specializing generalist” emphasizing that while you might want to specialize and be proficient in one or two disciplines (like business rules analysis, process analysis, etc.) you must also have a good understanding of all the other business analysis dimensions. Focusing on one area alone is like trying to sit on a one legged stool… you’ll be on the floor before you know it.

Identify Business Rules

When eliciting requirements, it is great if you are able to identify business rules as soon as you hear them even they might not be labeled as such by your stakeholders. To accomplish this, Mary suggests that the analysts watch for certain key words which serve as business rule giveaways.

Here are some of the business rules clues:

classify,
determine,
compare,
assess,
evaluate,
must,
defined as,
must not,
calculated as,
must only,
If … then …
etc.

Business Rule Classification

Term Rule: a business rules which defines a term of the business…. In every business domain it is critical to document all the rules defining the vocabulary to be used on the project.

Example 1: A Customer is defined as an individual or organization who purchased a product in our store.

Example 2: A Gift Card is defined as a product sold by our store that in turn can be used as a payment for other purchases.

As you can probably guess, your project glossary is a set of term business rules.

By the way, for more details on business rules in the context of requirements elicitation process check out the The Software Requirements Memory Jogger.

Fact Rule: Is a business rule which is part of the “fact model” (think logical data model) which outlines our understanding of truth related to previously identified terms.

Article 3.2 of the Business Rules Manifesto states: “Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.”

Example 1: A Purchase is paid for by Gift Card, a Gift Card pays for a Purchase (shows the relationship between Purchase and Gift Card).

Example 2: A purchase may be paid by one or more Gift Cards, A Gift Card may pay for one or more Purchase (shows the cardinality between Purchase and Gift Card).

As you can see from the above two examples, fact rules are really facts which are generally documented and captured by logical data models of your system.

This example also reinforces the concept that while doing analysis of the business rules you will discover data requirements (business entities and their attributes) such as: customer, customer e-mail address, gift card, gift card balance (entity vs. attribute).

It is not possible to analyze business rules and not consider data requirements:

Fact Rule: a customer has a name and address
Data Attribute: customer first name, customer last name, customer semail address (attributes are atomic – cannot be broken down any further)

Constraint Rule: is a business rule which places a constraint on data entities or data attributes.

Example: A Gift Card’s expiration date must be equal or greater than the Purchase’s purchase date.

Again, from the rule above you’ll see that we just discovered a data requirement to track and store yet another piece of data => Gift Card Attribute: expiration date (we need to remember the date in order to be able to enforce the constraint rule).

Derivation Rule: Is a business rule which explains how new data may be derived from other data. Think of these as calculations.

Example: Gift card expiration date is calculated as Gift Card activated date plus 365 days.

And, of course, here is another new data requirement -we need to store yet another Gift Card Attribute: activation date.

Did you see how rules drive data – you discover data as you discover and document the rules.

Data Attribute Rule: Is a business rule which provides constraints on data attributes.

Example 1: Customer’s middle initial is an optional attribute when of purchasing a Gift Card.

Example 2: Gift Card Status has four allowable options: Purchased, Activated, Expired, and Depleted.

Mary suggested using a table as one option for capturing and documenting data attribute rules, such as:

Attribute Name	Definition	Required	Allowed Values	Data Type	Maximum Value	…
Customer first name	…	Yes – when creating a new customer	n/a	Alpha	n/a	…
Customer last name	…	Yes – when creating a new customer	n/a	Alpha	n/a	…
Customer middle initial	…	No	n/a	Alpha	n/a	…
Gift card purchase amount	…	No	n/a	Currency	n/a	…
Gift card status	…	Yes	Purchased, Activated, Expired, Depleted	n/a	n/a	…
Gift card original balance	…	Yes	n/a	Currency	$1,000.00	…

Of course, you can add additional columns to capture more detailed requirements about your data attributes such as: format/mask, minimum value, range of values, etc.

Separation of Concerns

Do your data definitions belong in your use case (or other behavioral artifact)?

Do your business rules belong in your use case (or other behavioral artifact)?

NO! They need to be in a separate/shared repository so that they can be reused.

One of the key concepts which were stressed in this session was the separation of concerns. While you may be doing it all during the requirements process: rules, data, process/behavior you also need to ensure that you have a way to manage the project’s processes, data, business rules, etc. as separate (yet interconnected) models rather than dumping your requirements into one catch-all document or format.

In her session, Mary Gorman covered many other topics related to business rules but this post would have been even longer. Sorry - but I guess you'll have to hear her in person.

If you’re interested in my notes from Mary’s other WCBA session, visit: Jogging through the IIBA® BABOK® with the Requirements Roadmap

Useful Business Rules References

Book: Business Rules Concepts by Ronald Ross

Article: Business Rules and Data Requirements by Mary Gorman

Article: Turning Rules into Requirements by Ellen Gottesdiener

Interview: What Analysts Need to Know about Decisioning and Business Rules - Interview with Ronald G. Ross

Business Rules Manifesto: The Principles of Rule Independence from the Business Rules Group

The Business Rules Manifesto*

Article 1. Primary Requirements, Not Secondary

1.1. Rules are a first-class citizen of the requirements world.

1.2. Rules are essential for, and a discrete part of, business models and technology models.

Article 2. Separate From Processes, Not Contained In Them

2.1. Rules are explicit constraints on behavior and/or provide support to behavior.

2.2. Rules are not process and not procedure. They should not be contained in either of these.

2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1. Rules build on facts, and facts build on concepts as expressed by terms.

3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.

3.4. Rules are basic to what the business knows about itself -- that is, to basic business knowledge.

3.5. Rules need to be nurtured, protected, and managed.

Article 4. Declarative, Not Procedural

4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.

4.2. If something cannot be expressed, then it is not a rule.

4.3. A set of statements is declarative only if the set has no implicit sequencing.

4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.

4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

4.7. Exceptions to rules are expressed by other rules.

Article 5. Well-Formed Expression, Not Ad Hoc

5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.

5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.

5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

Article 6. Rule-Based Architecture, Not Indirect Implementation

6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.

6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

6.4. Rules are based on truth values. How a rule’s truth value is determined or maintained is hidden from users.

6.5. The relationship between events and rules is generally many-to-many.

Article 7. Rule-Guided Processes, Not Exception-Based Programming

7.1. Rules define the boundary between acceptable and unacceptable business activity.

7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.

7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.

Article 8. For the Sake of the Business, Not Technology

8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.

8.2. Rules always cost the business something.

8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.

8.4. ‘More rules’ is not better. Usually fewer ‘good rules’ is better.

8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

Article 9. Of, By, and For Business People, Not IT People

9.1. Rules should arise from knowledgeable business people.

9.2. Business people should have tools available to help them formulate, validate, and manage rules.

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

Article 10. Managing Business Logic, Not Hardware/Software Platforms

10.1. Business rules are a vital business asset.

10.2. In the long run, rules are more important to the business than hardware/software platforms.

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

*Version 2.0, November 1, 2003. Edited by Ronald G. Ross.

Copyright, 2006–2009. Business Rules Group.

Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyright and this permission notice are clearly included. (b) The work is clearly credited to the Business Rules Group. (c) No part of the document, including title, content, copyright, and permission notice, is altered, abridged, or extended in any manner.

Dispatches from the WCBA Conference: Retrospectives

Adrian M. — Wed, 18 Nov 2009 18:51:00 GMT

Dispatches from the WCBA Conference: Retrospectives

“Slow Down to Speed Up: Retrospectives for Improving Product and Process” was the title of one of the workshops I attended during day two of the WCBA conference.

Ellen Gottesdiener, Founder and Principal Consultant, of EBG Consulting tackled the subject of “Retrospectives”.

It was a great presentation and included a number of topics including:

What are Retrospectives?

“Retrospective – a ritual in which the entire project community comes together: reviews the iteration/release/project story (something which just finished), harvests the collective wisdom of the teams, tells the truth without blame or judgment, identifies what to appreciate and improve, understands and forgives its failings, and relishes in its successes.”

In a nutshell, it’s our chance to look back in the rear view mirror and learn from what just took place. The insights gained from retrospectives become the basis for improvement, both immediate and longer term.

Careful using terms such as postmortem (are you assuming you project is dead?)…

In order for a retrospective session to provide value, it must address 5 key questions:

· What did we do well that we might forget if we don’t discuss it soon?

· What did we learn?

· What should we do different next time?

· What still puzzles and intrigues us?

· What needs more in depth discussion and analysis?

When should Retrospectives take place?

The traditional practice for doing retrospectives or postmortems (if your project is dead projects) is at the end of the project. The problem with this approach is that on projects with longer duration the value and benefit of the retrospective diminishes as it is far removed from when most of the project activities took place.

Alternately, retrospectives can be done sooner than the end. For projects which have a set rhythm (regular iterations, regular releases, etc.) a retrospective session can be done at after of each of the repeating phases.

Lastly, you should also consider an ad-hoc retrospective as a valuable tool when you get caught by surprise by a project challenge or other significant unplanned event in the life of the project.

Why Retrospectives?

As with everything else that we do, retrospective must provide value in order to be worth the time and energy. Ellen explored the value proposition of this tool.

In a nutshell, retrospectives are a great way to harvest the collective wisdom of the entire project team by giving everybody a chance to tell the story from their perspective and to discover things that happened on the project that you did not know about.

Retrospective is a great method of free adaptive learning:

· Immediacy – doing the retrospective as soon as possible ensures the recent experiences are sharp in the team’s memory,

· Relevance – the learning is relevant because the team has a common vested interest in the project/milestone/iteration/release what just completed,

· Self-Direction – most of us we don’t like to be told what to do ->retrospectives allows the individual contributors to identify and choose what they want to adapt and change going forward.

Retrospectives that Work

A retrospective is a great community participation-based tool which works because needed change is identified, proposed, and implemented by the project team and not simply shoved down their throats by some executive who is disconnected from the day to day realities of the project.

Successful retrospectives:

· Use data -> how many stories we implemented as opposed to the last iteration, how many test cases per story, how many defects per function point, etc.

· Acknowledge individual feelings -> Remember that feelings do count!

· Have a pre-defined structure –since everybody knows that it will take place, it provides the freedom to participants to identify and implement change without fear or guilt.

A good structure for your retrospective session looks like this:

1. Readying – set the stage

2. Past – gather data

3. Present – generate insights

4. Future – decide what to do

5. Retrospect – close the retrospective (retrospect the retrospective)

Retrospective = basis for change – it’s really a very cheap, yet effective, change management strategy

Dispatches from the WCBA Conference: Jogging through the IIBA® BABOK®

Adrian M. — Tue, 17 Nov 2009 08:55:00 GMT

Here’s a dispatch from the first day at the World Congress for Business Analysts (WCBA).

I attended an all-day workshop titled “Get the Right Stuff, Fast: Jogging through the IIBA® BABOK® with the Requirements Roadmap” lead by Mary Gorman of EBG Consulting.

Mary is a Certified Business Analysis Professional™ (CBAP®) and works as Senior Associated for EBG Consulting, assisting teams to build the right products through exploring and confirming their requirements.

If Mary’s sessions was a jog, then this blog post will be a sprint – a very fast one, I might add!

The focus of the workshop was to:

Leverage the Requirements Roadmap to articulate requirements
Align requirements models to knowledge areas in the BABOK®
Create a set of interconnected requirements models to speed up the requirements development and successfully engage business users and customers.

During the session, Mary provided great insights on the business of “business analysis” specifically focusing on defining the scope of and modeling user requirements using the requirements roadmap:

You can get the PDF version of the requirements roadmap from EBG’s website.

During the session we raced (ok, just jogged) through the roadmap with pointers to sections in the various BABOK® knowledge areas:

Business Analysis Planning and Monitoring
Enterprise Analysis
Elicitation
Solution Assessment and Validation
Requirements Analysis
Requirements Management and Communication

Regardless of what methodology or techniques you use, Mary pointed out that it is important understand that we need to have a balanced perspective of the requirements through the lens of four fundamental model views:

Behavior: e.g. process, action, function, task, script
Structure: e.g. information, data, object
Dynamics: e.g. time, lifecycles
Control: e.g. business rules

The session slide included a nice Vann diagram of the four models with the control model being at the intersection of the behavior, structure, and dynamics models.

Jogging along… the session covered a number of techniques, including:

Stakeholder & Actors: Customer vs. User vs. Others => Ask: “Who?”

Glossary & Data Model: The building blocks for later constructs such as business rules => Ask: “What?”

Event-Response Tables: An effective tool to elicit user requirements => Ask: ”When?”

Use Case & Scenarios: Describe the flow of the actor-system interactions => Ask: “How?”

Business Policies & Business Rules: Statements that constrain some aspect of the business => Ask: “Why?”

The practical side of the workshop was the case study which forced everyone to roll-out their sleeves and put in practice the techniques discussed.

It was a cozy sessions with many chances for everybody to participate. Most of the session attendees got a free copy of the Software Requirements Memory Jogger.

- Adrian

Adrian Marchis
Publisher, ModernAnalyst.com

The 8 key responsibilities for Business Analysts on software projects

Adrian M. — Sat, 04 Jul 2009 04:24:00 GMT

I stumbled upon a great blog post by Jerry Nixon, Principal Architect for NixonCorp, which covers from a developer's perspective eight reasons why Business Analysts bring value to a project through what they do:

Extract
Anticipate
Constrain
Organize
Translate
Safeguard
Simplify
Verify

Read Jerry's post for the details.

- Adrian
Adrian Marchis
Publishing Editor, ModernAnalyst.com

I want to be a Business Analyst… Raise me, mentor me, and set me free!

Adrian M. — Sun, 07 Jun 2009 22:05:00 GMT

“Once upon a time, young people learned a trade through years of apprenticeship.”

Have you noticed an interesting dilemma faced by those wanting to enter the business analysis profession?

There don’t seem to be any “Junior Business Analyst” jobs. Most hiring organizations are looking for practitioners with prior business analysis experience.

Imagine wanting to begin a career as a driver and being told “You can’t drive the car until you know how to drive a car.”

And when you ask for advice on how to learn to drive a car you get answers such as:

“Here’s a list of good books about driving cars.”
“Talk to other drivers about their experience and how they got started.”
“Try first a related career such as car washing, car repair, etc.”
“Subscriber to Car and Driver magazine.”
Etc.

Sounds silly?

Well –that seems to be how we treat newcomers to our profession:

Managers want to hire the experienced Business Analysts for their projects but they don’t seem to want to grow BAs, and
Experienced practitioners want to work with and learn from other experienced BAs but they don’t want mentor junior ones.

Is business analysis a really a profession? Are we there yet?

I’m not so sure!

In most mature professions you will find that, in addition to the educational requirements which may exist, there is always a “practical” component to the path to getting started as a newbie:

Carpenters, auto mechanics, and plumbers have apprentices who are taught the trade.

Medical school graduates go through lengthy residency and fellowship programs where they gain real experience.

Law enforcement academy graduates are generally assigned to a training officer with whom they will spend months, if not years, on the street learning the realities of the profession.

If you want to learn to drive a car you are allowed to get behind the wheel and learn to drive even before you master the skill enough to pass the driver’s test.

That’s what we need in our profession!

We need managers, practitioners, visionaries, and leaders who are willing to hire newbies and help them start their careers as business analysts.

If you’re a newbie I bet you would love to find an organization who is willing to hire you right out of school/training, get you started as a business analyst, mentor you, and the launch you into a successful business analysis career! Wouldn’t you?

Helpful resources:
In this month’s issue of the Modern Analyst eJournal, you’ll find some great thought leadership on the value of and establishing Business Analysis Communities of Practice (BA COP) or Business Analysis Centers of Excellence (BA COE) which can act as the starting point of BA apprenticeship and mentoring programs.

Also in this issue you’ll find insightful articles on the Business Analyst Career Progression and the Potholes of Office Politics that new BAs may be faced with.

And in the spirit of providing you with a solid technical background, we continue our SOA series with an introduction of More Confusing SOA Terms.

- Adrian

Adrian Marchis
Editor, ModernAnalyst.com

Agile - the way I like it...

Adrian M. — Mon, 11 May 2009 10:00:00 GMT

This month’s eJournal issue is about Agile and the Agile Business Analyst with a couple of great articles by Ellen Gottesdiener and Scott Ambler exposing upon the agile side of the business.

At ModernAnalyst.com we try really hard to showcase editorial content which is relevant, educational, well balanced, and thought provoking. For the most part, as an editor, I try to stay on the sidelines when it comes to controversial topics such as the Agile vs. Traditional methods.

Yet today I couldn’t resist chiming in! Ouch!

I tend to be a middle of the road guy and, in general, I try not to get stuck on any one of extremes – regardless of subject or topic. My belief is that if it works for me then I’ll continue to use it and I also strongly advice you that if it works for you then you should continue to use it – whatever it is.

But Jason Gorman puts it my better:

If it works, do it
If it works, it works
If it seems to work, it probably works
If it seems to work, it probably works – and might work again

He calls this The Post-Agile Manifesto (disregard the toilet – I haven’t figured that one yet). For more, here’s a Post-Agilism FAQ.

The idea is that fanaticism is not a good thing on either side of the fence. Some agilists when they hear of waterfall projects which succeed, claim the team must have used agile and gave the process a wrong title. Traditionalists who witness successful agile projects call them hacks destined for eventual failure.

As a business analyst, trying to make sense of it all, you might find yourself thinking “agile is bad” because there doesn’t seem to be a well defined role for the BA on an agile team or, perhaps, you’ve started your career as an agile BA and cannot comprehend while anybody in their right mind would want to write a 100 page requirements document.

Unfortunately, the debate between agile and traditional software development processes is alive and well with both side of the camp continuing to fire salvoes at each other.

The truth, as I see it, is probably somewhere in between - as I’m sure you’ll find examples of success stories where:

Agile methods were used to develop large-scale applications,
Traditional methods were employed on small projects,
Agile teams utilized use case narratives,
Traditional teams created user stories to document requirements,
Etc.

The reality is somewhere in between the Traditional Methods and the Agile Manifesto with:

many traditional processes such as the Rational Unified Process (RUP) incorporating agile iterations and other agile concepts, and

agilists turning to more structure and formal processes as witnessed in the Enterprise Unified Process (EUP).

Since this month’s eJournal issue is on Agile – let’s get back there!

Is Agile bad?

No.

However, the type of agile movement that I like is the one that realizes that “agile” is not the end goal.

Creating value is a good goal.

Solving business problems is where it’s at.

Getting the job done is what’s important.

If it works, use it – whatever it is!

Do not be afraid to use what works, don’t shy away from learning something new, and keep on improving our profession and craft regardless what the end process/methodology may be called.

- Adrian

Adrian Marchis

Publisher, ModernAnalyst.com

PS: Are you scared of Agile?

Disgusted with Traditional methods?

What’s on your mind?

I’d love to know!

April 09 Editor’s Note: Should the BA care about BPM and SOA?

Adrian M. — Sun, 05 Apr 2009 21:23:00 GMT

Yep!

OK… this could have been a really short editor’s note but I’ll wait to practice word frugality for my Twitter posts. Yep – you can now follow me and other Modern Analyst editors on twitter: http://twitter.com/ModernAnalyst.

Now back to BPM…

First, I’ll resort to some simple logic:

The backbone of any reputable business is a set of carefully defined business processes which govern how the organization should function (I recommend reading The E-Myth Revisited).
The business analyst role entails understanding how a business organization functions to accomplish its goals (see the business analysis definition in the BABOK 2.0, which has been recently released).
Therefore => BPM is very relevant for the BA! As a matter of fact, BPM should be done by the business analyst.

Business Process Management (BPM) refers to the discipline which business owners and managers employ to think about, understand, and improve upon how a business works in order to accomplish its goals.

This entails:

Business Process – a set of coordinated activities and tasks whose purpose are to accomplish a something of value for the organization.

AND

Management – the practice of (1) planning, (2) organizing, (3) directing, and (4) controlling.

The value of the business analyst is, perhaps, never more apparent then when he/she is involved in planning, organizing, directing, and controlling business processes which aim at enabling the strategic goals of the organization.

In this month’s issue of our eJournal we’ve provided a ton of great content related to business processes and BPM.

A word of caution: while I believe you should master business process management, be careful when and how you apply these skills.

On to SOA…

While many business analysts would be content to stay exclusively focused on the business side of the house, the reality is that, in today’s world, technology is at the core of almost any business initiative. Service Oriented Architecture (SOA) is a system architecture paradigm which is widely used to design and implement the technology behind many process-centric applications.

John Moe’s SOA Column debut has a good introduction to the subject: “SOA What: SOA 101 for Analysts”

If you are a Systems Analyst, then SOA is even more relevant since you may be called upon to design and specify services which will be used as part of a service-oriented type application. We’ll cover more details related to service specifications in future articles.

What are your thoughts on the relevance of BPM & SOA for the BA?

Do you work in an environment where BPM & SOA is used?

- Adrian

Adrian Marchis

Publishing Editor

ModernAnalyst.com

Computer Systems Analyst: Career that Pays Well Even in a Recession

Adrian M. — Mon, 16 Mar 2009 07:14:00 GMT

In a recent Yahoo! Hot Jobs article, Grace Chen identifies 5 Careers that Pay Well Even in a Recession:

Engineer
Accountant
Marketing and Sales Manager
Registered Nurse
Computer Systems Analyst

According to the article - nearly 150,000 new jobs for computer systems analysts are expected to be created between 2006 and 2016.

This is yet another piece of good news for our profession.

For more details on the Systems Analyst vs. Business Analyst see:

Business Analyst Roles AKA “In Search of the Business Analysis Holy Grail”

- Adrian

Could the Recession be Good News for Business Analysts?

Adrian M. — Mon, 09 Mar 2009 05:56:00 GMT

Most of us would agree that recessions are not a good thing – especially the one we are in right now.

But for those daring enough, tough times have can be moments of opportunity.

Many famous companies - such as GE, CNN, HP, Microsoft, Hyatt, FedEx, etc. - started during times of shaky economic conditions.

How did this happen?

They were started by people who recognized a market need and who worked diligently to fill that need. This is the key to starting and building thriving enterprises.

You may not be starting the next Microsoft but there are great opportunities for you, the business analyst, in these tough economic times.

Let’s take a look…

[1] In a down economy businesses tend to refocus on the bottom line: increasing efficiency, reducing costs, and identifying opportunities within the realm of their core competencies. Businesses are now ready to (perhaps forced to) slow down and take a closer look at their Business Architecture as well as employ Enterprise Analysis techniques in order to identify new opportunities.

Who is going to help these organizations with these tasks?

You got it!

It’s YOU, the business analyst…

[2] Many companies, for good or bad reasons, attempt to cut costs by outsourcing and off-shoring new system implementations and software development activities. To enable this, they must employ consultants or employees who understand the business needs/goals and interface with the outsourced providers.

Who do you think is best suited for this task?

You got it again!

It’s YOU, the business analyst…

[3] Have you heard of TARP, Stimulus, or Bailout?

Well – billions of dollars have been set aside to help banks, mortgage, and insurance companies. Attached to these dollars come many new rules, regulations, and conditions. The recipients and hopeful recipients of this money are busy trying to understand and implement the impact of these new rules into their business models, processes, and systems.

Who can benefit from this additional work?

Yep… the Business Systems Analyst, the Process Analyst, the Systems Analyst!

[4] Have you seen the various other changes being proposed though either specific plans or the new proposed budget for rest of 2009:

Numerous tax code changes – do you think the IRS, tax software companies, tax accountants, investment firms, etc. will have to change their models and business software? You bet they will!
Money to Modernize Air Traffic Control Systems – they’ll need top notch systems analysts. Are you one?
Enhance security at Major Ports – this will include many technology projects especially related to security. This might be a good niche for technical Bas who don’t mind learning a thing or two from a Security Analyst.
Align our Education with 21^st Century economic demands – this means science and technology… The might need folks who not only understand technology, know how technology can solve problems, but who can also communicate, teach, and mentor… Many business analysts are great at this!!!
Computerize America’s Health Records & Change the health care system. Do you have healthcare vertical domain knowledge? If you don’t get some, ‘cause this industry could potentially see some of the more drastic changes requiring new processes and business systems. By the way – we have a related free webinar coming: “Visualizing an Electronic Record System: A Case Study for BAs”
Developing and Disseminating Info on Effective Medical Interventions – $1.1 billion dollars have been slated for researching this data. Do you foresee the need for new systems based on solid Enterprise and Data Architecture? I do.
Etc., etc., etc.

It is up to you to identify these opportunities and niches which fit your skills and interests.

By the way – did you notice this month’s eJournal topic: Enterprise Business Analysis & Architecture!

This is the time to look at the big picture and identify trends which could either help or hurt you or your organization.

You mission, should you choose to accept it, is to identify these trends and changes and act appropriately.

This is NOT Mission Impossible… Enterprise Business Analysis is the discipline which will help you do just that.

Any thoughts of what opportunities might be there for you?

Would love to hear your ideas!

- Adrian

Adrian Marchis

Publishing Editor

ModernAnalyst.com

Which Business Analysts are in demand: The Reality!

Adrian M. — Tue, 17 Feb 2009 08:01:00 GMT

I've heard and read many opinions painting the role of the business analysts as being (or needing to be) purely business oriented. The argument is "let the technical team deal with the technical details."

The practice however, the business analyst is confronted by the technical aspects of the solution on virtually every project. These days - it is a rarity, if at all, to find a business project or initiative which does not involve some level of system support.

A recent article in the discussing the state of the Australian job markets commented on the fact that:

"The roles in demand this year will include project managers, architects and business analysts with technical skills."

That has been my observation as well... at least in the USA.

There seem to be very few Business Analyst job postings out there which do not include some level of demand for some technical skills.

Would love you hear your thoughts and comments!

- Adrian

The Business Analyst will probably go down...

Adrian M. — Mon, 09 Feb 2009 08:01:00 GMT

The Business Analyst will probably go down as one of the more important players to help us get out of these terrible economic times.

Now is more important than ever for organizations to improve their processes and squeeze every last bit of productivity out of their business operations. Unfortunately, not all companies will survive - as they try to go at it without thorough business analysis.

Recently I've heard a business executive say something like "last time we've done this type of endeavor things went really bad so this time I'm giving you guys more time". This sounds like a line straight out of a Dilbert cartoon.

Does more time really guarantee success?

Of course not!

Last night I saw all over the news how both Republicans and Democrats battle for the details of the stimulus bill with some saying that getting the bill approved in a timely manner is more important than arguing over the details. Really?

Does spending lots of money (hundreds of billions in this case) guarantee success?

Does acting fast really ensure the desired outcome?

Of course not!

Then what?

Good, solid, and creative Business Analysis!

Our business organizations and our government must make decisions (paralysis is not an option) but they must make the right decisions. Business analysis is the process for analyzing an organization’s problems for the purpose of arriving at effective solutions and effective decisions.

In this month’s eJournal you will:

learn how to use decision management to improve business analysis,
find out how to develop an eye for waste by looking at seven wastes of software development,
discover how to apply creativity in your day to day job, and
hear how to use process mapping to tap into new markets..

And when you’re tired of worrying about your projects – take time off and enjoy some BA Humor.

- Adrian

Adrian Marchis
Editor, ModernAnalyst.com

Possess a Clear Understanding of Business Analysis

Adrian M. — Tue, 27 Jan 2009 07:47:00 GMT

As a programmer who moved into business analysis I got most of my business analysis skills the old fashioned way:

through trial and error,
working on many projects,
stealing from those who succeeded,
learning gotchas from those who failed,
etc.

It was rare when I stumbled upon an experienced consultant who was willing to mentor and who was able to explain the details of the craft.

Chances are, if you want to become a valued business analyst, you will also have to learn the old fashioned way. But, lucky you, there are many resources popping up geared specifically towards business analysts - including books such as:

Seven Steps to Mastering Business Analysis by Barbara A. Carkenord
Getting It Right: Business Requirement Analysis Tools and Techniques by Kathleen B. Hass, Don Wessels, and Kevin Brennan
Professionalizing Business Analysis: Breaking the Cycle of Challenged Projects by Kathleen B. Hass
The Business Analyst's Handbook by Howard Podeswa

I must admit that I'm guilty!

I didn't rush out the door to buy any of these books. I guess I'm still stuck in my old habits of learning by doing.

Having said that, I was lucky enough to get my hand on a copy of Barbara's book Seven Steps to Mastering Business Analysis (thanks to J.Ross Publishing).

I just got through reading the first chapter and...

... I'm impressed (so far)!

The first chapter, Possess a Clear Understanding of Business Analysis, provides a great overview and introduction to our profession.

Through logical explanations and 'case in point' examples, Barbara takes the reader through the basics of understanding the roots, role, and future of the business analyst.

She talks about a number of things such as:

What is Business Analysis? - she mentions:

"Identification of business problems and opportunities"
"Elicitation of needs and constraints from stakeholders"
"Analysis of stakeholder needs to define requirements for a solution"
"Assessment and validation of potential and actual solutions"
"Management of the product or requirements scope"

The Role of the Business Analyst - with good insights into:

Business Analyst traits
History of Business Analysis - I particularly liked this section because it clearly spoke from Barbara's experience on real projects in real organizations.
Where do BAs come from (IT vs. Business)
Where business analysts report

Who Makes a Great Business Analysts - includes:

A list of "the BA must..."
A Business Analyst Suitability Questionnaire
Career progression for the business analyst

Key Business Analysis Concepts - such as:

What is a Requirement?
What is a Project?
What is a Product?
What is a Solution?
What is a Deliverable?

This section also makes a good case for "Why Document Requirements?" which is nice to see in the midst of all the hype about Agile and "documentation is bad" rhetoric. I've worked on enough large scale projects which would have not survived without documentation.

(If you're wondering: I prefer "just enough" documentation!)

So far, the book has proved to be a good an easy read. I'll keep you posted on my thoughts as I progress further in the book.

- Adrian

Demand for Business Analysis skills is still strong

Adrian M. — Tue, 27 Jan 2009 07:03:00 GMT

"The 2009 Benchmark of Salaries and Employment Trends in IT survey from the National Computing Centre says one-third of respondents have experienced a shortage of candidates with certain key skills.

According to the survey, 33.7 percent of organisations highlight problems recruiting or retaining people with Oracle, SAP, .NET, web development, business analysis and network support skills."

- from ZDNet.co.uk

Despite the current economic downturn, finding skilled business analysts is not easy.

My guess is that there are many newcomers to our profession who are trying to get started in a hurry but how don't yet have much experience or formal training. The good and experienced BAs probably already have jobs and are staying put until the economic conditions improve.

For those of you who are new/aspiring analysts - this is a great time to take some time off (if you don't have a job anyway) and get a formal degree or training in business analysis.

- Adrian

What will you do to increase your value as a Business Analyst?

Adrian M. — Fri, 09 Jan 2009 07:52:00 GMT

I’ve had the chance to interview numerous candidates for business analyst positions and there is one question I like to ask every one of them:

“What do you do to increase your skills and value as a Business Analyst?”

Obviously, I’m not looking to get a specific answer as each business analyst has different background and different goals.

What I’m looking for are those analysts who have a passion for their career and who are constantly seeking to improve their skills and the value they bring to the project or organization.

Sadly, very few candidates answer this question to my liking. Most folks out there expect somebody else to take care of them: my co-worker is supposed to mentor me, the boss is supposed to train me, the project manager needs to give me clear instructions, the recruiter should revise my resume, etc…

You don’t want to be one of them… that’s not a trait of a business analyst!

So what should you, the Business Analyst, do in 2009 to improve your value and skills?

Well, there isn’t only one answer – it’s ultimately up to you to decide – but here are some ideas:

Read a new book (here’s a new one: Seven Steps to Mastering Business Analysis)

Offer to mentor and coach a more junior business analyst on your project or in your organization.

Become actively involved in your profession. If you’re reading this then you already stumbled upon ModernAnalyst.com (which is awesome). Now consider contributing your experience, thoughts, and view though blogs, forum posts, or articles.

Attend a course, workshop, or event related to business analysis.

Learn a new tool or technique (see: Getting It Right: Business Requirement Analysis Tools and Techniques) and then create a presentation to teach others what you’ve learned.

Attend a local IIBA Chapter meeting (get a list here).

Wishing you a Happy and Prosperous New Year!

A Business Analyst in Obama's Administration?

Adrian M. — Fri, 09 Jan 2009 06:56:00 GMT

Recently, the media was buzzing with news that president-elect Obama named Nancy Killefer, a management consultant with McKinsey & Company, as the nation's CPO.

That is Chief Performance Officer.

According to the media "the newly created position aims to make government more efficient, effective and transparent".

I don't know what a CPO does but it surely sounds and smells, especially given Nancy's consulting background, like a business analysis position.

And if you're still wondering what in the world is a Chief Performance Officer then check out:

CPO Book: Chief Performance Officer

CPO Blog: Measuring What Matters, Managing What Can Be Measured

More References:

http://money.cnn.com/2009/01/07/news/economy/performance_officer/index.htm

http://www.washingtontimes.com/news/2009/jan/07/obama-names-management-consultant/

A framework for defining competencies for business systems analysts

Adrian M. — Mon, 09 Jul 2007 02:48:00 GMT

If you are managing business or systems analysts, trying to identify the skills and competencies required of your analysts is not an easy task. The expectations placed upon the analyst vary widely from organization to organization. The variations are so drastic that the actual title doesn’t not say much about the type of work your analysts do.

I have interviewed business analysts who have only worked on the business side and were never involved in the creation or modification of a system. On the other hand, I have met business analysts whose only responsibility was to create functional specifications.

OK… so what does this mean?

First, let me say this: “It’s not what you’re called, it’s what you do!”

What this means is that you should not try to figure out the skills and competencies of an analyst by their title – you need to know exactly what types of tasks you are expecting your analysts to perform.

In order to do that I like to put some structure around this topic to help you discover the skills and competencies expected of your analysts.

Let’s try!

- The Analyst bridges the gap between business & technology.

- The analyst plays a number of roles.

- To perform each role, the analyst draws knowledge from a set of disciplines.

- Each discipline defines a set of activities which the analyst performs.

- Each activity takes inputs and produces outputs.

- Each activity requires a given set of competencies.

- These competencies may include analytical, business, and technical skills.

Simple Definitions:

Analyst = this refers to the person whose title is generally business analyst or systems analyst but may have titles as diverse as: IT Business Analyst, Requirements Engineer, Computer Analyst, Functional Analyst, etc.

Role = The role refers to the analysts’ expected function in a given project or team. It speaks to the behaviors, rights, and responsibilities that are expected from the analyst in a given context. This is where we often get in trouble as the role of the analysts changes from project to project and task to task. Many analysts have what is known as “role confusion” in the situations when he/she has trouble figuring out exactly the role(s) they are supposed to play.

Discipline = A discipline represents a branch of knowledge (part of a larger body of learning) which defines a set of activities to be performed as well as the competencies needed to perform the given activity. For example, “testing” is a discipline which defines a set of activities and competencies needed by a QA analyst while testing software,

Activity = An activity represents a task or effort that is expected to be performed by the analyst in the context of a given role. Each activity must be clearly defined as is usually represented as having: a purpose (why perform the activity), outcome (what are the results/artifacts of the activity), and a method (how to perform the activity).

Competency = In general, competency refers to one’s ability (qualification and capability) to perform a given activity. In the case of the analyst, this requires an appropriate mix of knowledge (theoretical understanding), skills (practiced ability) and attitudes (way of thinking and opinions).

At a high level, I like to categorize the competencies needed by business analysts and systems analysts as follows:

Analytical competencies – because first and foremost, the analyst is supposed to “analyze” – obvious but often overlooked by many organizations.
Business competencies – because the analyst is expected to understand and solve business problems.
Technical competencies - because, in many cases, business problems are solved using technical solutions (information systems).

Any thoughts? Would love to hear your feedback!

Tablet UML

Adrian M. — Thu, 05 Jul 2007 02:41:00 GMT

In most of the projects and organizations I have worked for I have seen a very interesting pattern:

- Developers get developer specific tools such as MS Visual Studio.

- Testers get testing specific tools such as Mercury TestDirector.

- Analysts get MS Word, Excel, and PowerPoint. The more "progressive" organizations might provide their business analysts and systems analysts with Visio.

Wow... cool!

If you think I'm venting, you right? I am venting!

To tell you the truth: I don't get it!

There are so many great tools for requirements management and system modeling yet most organizations have not yet realized that spending a few bucks on tools for their analysts can actually improve productivity and save them money in the long run.

My gut feeling tells me that this problem is closely tied to the view of the business analyst. The business analysis, as a profession, it's just beginning to bud.

I'm hoping that, soon, most organizations will begin to realize the value that business analysts and systems analysts bring to the table. When that happens, the shortage of qualified analysts will be evident and companies will try to find other ways to increase productivity. An adequate tool is one such way!

But I digress...

What triggered these thoughts (again) was that I stumbled upon a UML tool for the Tablet PC called Tablet UML. While I have not used the product - it's a very intriguing idea. Imagine being in a JAD session or brainstorming meeting and, instead of pen & paper, using a tablet PC to capture the models being discussed.

Technologies and tools such as these are going to become more and more important and valuable as organizations realize the importance of analysts and attempt to find new ways to increase their productivity.

More on how to deal with bad requirements

Adrian M. — Sun, 24 Jun 2007 02:26:00 GMT

After posting my last entry on questioning suspect requirements, I've read a great piece on the SlickEdit blog titled "How to Design Software With Bad Requirements."

Scott offers some practical tips to help developers deal with bad requirements. These also apply very well to business analysts and systems analysts:

come up with good use cases - to help the business user visualize the system or process scenarios which do not make sense,
create a prototype - if the end user's request can be modeled using a UI prototype, do so - they may see the light,
abstract and encapsulate - assume that these requirements will change eventually and design your system in such a way to be able to easily modify it in the future,
don't get discouraged - keep your spirits up and make the best out of the situation.

Systems Analyst in the list of Best Careers 2007

Adrian M. — Sun, 24 Jun 2007 02:03:00 GMT

The Systems Analyst role is and will continue to be one of the best careers for a long time.

In their “Best Careers 2007” report, US News and World Report lists 25 professions that will continue to grow in demand.

With the advent of outsourcing, it is not surprising that the software engineer or web developer professions are NOT on the list...

...however, systems analyst is.

One of the most interesting quotes form this report is that the systems analyst "is among the most offshore-resistant computer-related careers".

Another interesting observation is that the majority of the 25 careers are high-touch/social occupations. In the US, we continue to see a trend of increased demand for careers which requires social interaction skills. Business Systems Analyst is one of them.

A couple more items of from the report about the Systems Analyst:

Median pay: $70,438
Job Market outlook: A
Attainability: A
Quality of Life: B
Prestige: B

If you are contemplating starting your career as a systems analyst you might also find the following resources useful:

A Day in the Life of a Systems Analyst

Computer Systems Analyst profile (U.S. Department of Labor)

Systems Analyst Community

Systems Analyst Resources

Salary Info for Business Systems Analysts

5 Traits of Successful Projects

Adrian M. — Mon, 11 Jun 2007 01:30:00 GMT

Michael Vinje, an I.T. and software engineering specialist with more than two decades experience, has written an article on 5 Traits of a Successful project.

Anyone in charge of business analysts or systems analysts can benefit from understanding and analyzing these traits. Here is a rather quick summary:

1. Balance demand with capacity. Simply put: know your available capacity, estimate carefully, and do not over commit.

2. Dedicate resources the team can count on day in and day out. That is, do not allocate new tasks to resources already allocated. Also - make sure that you allocate the right type of resource (don't ask the SME to step into the role of business analyst).

3. Include skilled business analysts on the implementation team. Business and systems analysts must be are at the core of every IT project. The problems, needs, and requirements of the business must be clearly understood in order to succeed in any information technology project.

4. Rely on project managers that exemplify mature professionalism. Great execution management and leadership skills are a must for those in charge of the project.

5. Make fact-based decisions. Succesful IT teams rely on timely and accurate facts in order to respond quickly and appropriately to changing circumstances.

For full article, please see link to Baseline magazine:

5 Traits of a Successful Project